當我們在談論 Observability 2.0 時，最核心的轉變其實是「資料的定義」。

在 1.0 的思維裡，我們習慣把 Observability 和 Metrics, Logs, Traces 三大支柱畫上等號，但是這樣的分類使得資料過於分散，當故障發生時，我們也很難只透過其中一個支柱來解決問題。

於是 2.0 便提出了結構化日誌(sturctured log)的概念，只要事件資料足夠結構化，Metrics 和 Traces 都能從中衍生，不必再依賴三套獨立工具，如此一來，我們才能真正面對高基數（*註1）、高維度（*註2）的資料挑戰。

為了處理大規模的資料量而丟棄資料？

成本考量下，1.0 為了處理隨著系統規模而上升的資料量，往往得透過縮短資料保留時間，或者聚合完指標後丟棄底層日誌的方式來降低成本花費。這種縮短資料的保存期間，或者選擇聚合資料，丟棄底層日誌的做法，在三大支柱的工具幾乎相同。

三大支柱在處理大量資料時，通常會有以下的處理方式：

Metrics: 聚合後丟棄原始資料

時間序列資料庫將大量原始資料進行聚合，丟棄底層的原始日誌。這樣雖能讓我們理解系統的概觀，但是無法深入的了解故障背後的細節。

Traces: 取樣後丟棄

Traces 的資料保存會採取取樣(sampling)的方式，主要可以分為以下兩種：

• Head-based sampling: 在 trace 一開始就會決定是否要採樣，因為沒有其他線索能判斷是否要取樣，所以通常是隨機取樣
• Tail-based sampling: 當整個請求結束之後再決定是否採樣。但相較前者，需要花更多資源來處理。

Logs: 縮短保留窗口及分層儲存

日誌儲存可以透過縮短資料的保留窗口，或者分層儲存來處理資料量龐大的問題。資料不是在短時間後就被丟棄，或者是早早被丟進 frozen tier 的儲存層，若日後要撈取資料，也是一筆成本花費。

這也是為什麼有些團隊導入了可觀測性工具，但往往還是只能靠直覺去排查問題，因為資料都礙於成本問題，而被抽樣或者丟棄了。

2.0 的解決方案：重新定義觀測資料

2.0 主張系統要能暴露出「夠寬的結構化事件」，並結合現代化的資料湖架構來處理這些大量的結構化事件：

靈活的 Schema

除了系統可以暴露資訊量夠多的結構化事件外，儲存資料的 schema 也能支援任意寬度的日誌，並且欄位可以隨時間變化，不須事前定義。

OLAP 特性及欄式儲存

OLAP (Online Analytical Processing, 線上分析處理) 通常用於儲存和分析大量資料，特別適合進行聚合、篩選和跨維度的計算。

在實作上，OLAP 系統常見的設計是採用欄式儲存 (Columnar Storage)。這種方式的好處是：當查詢只需要特定欄位時，可以僅讀取相關的欄位，而不像 row-based 資料庫必須將整筆資料讀出。這讓查詢效能在分析場景下大幅提升。

透過下方的動畫，或許就會對兩者的搜尋方式有一些感覺。

row-oriented search data，即便我只想要提取Time, Location, Mobile Phone這三個欄位的資訊，仍要搜尋整張表效率較差

column-oriented search data，只需要讀取特定欄位，就能拿出資料，不需要全表搜尋

編按：本篇文章僅會對此做一個概觀的介紹。詳細的原理特性以及它們如何和其他可觀測性工具結合使用，將會在本系列文後半段進行介紹。

結語

截至目前，我們已經了解可觀測性是什麼、Observability 2.0 為什麼要重新定義資料，以及它在技術上的需求。但是，如果沒有合適的工具和標準，即便再完整的理論也難以落地實作。

因此接下來，我會花幾天的篇幅來介紹 OpenTelemetry，它是近年來最受關注的可觀測性標準。透過它的設計邏輯，我們將能看到如何把抽象的理論真正落地到日常的工程場景當中。

註釋

*註1：高基數 (High Cardinality)：指欄位中擁有大量唯一值，例如 user_id，大量的唯一值會使得搜尋時間序列資料時的效能變差

*註2：高維度 (High Dimensionality)：指事件資料包含非常多不同欄位，例如 API log 帶了設備、OS、版本等 20 個欄位，組合數過大導致查詢與儲存成本急遽上升

參考資料

AWS - OLAP 和 OLTP 有什麼區別？

Charity Majors - Observability is due for a version change: are you ready for it?

ClickHouse Blog: What is a columnar database?

Faiq Buttar - What is OLAP and how can you use it in data warehousing?

Todd Persen - Observability 2.0? Or Just Logs All Over Again?